Industry increasingly depends upon highly automated data acquisition and control systems to ensure that industrial processes/operations run efficiently, safely and reliably while lowering overall costs. In such systems, data acquisition begins with sensors measuring current values/status of process variables representing the status/operation of an industrial process or operation. The measurements are communicated to programmed controllers and data collection/management systems. The data collection/management systems, generally including process databases and data processing routines, manage and maintain the measurement data. Such data management and maintenance includes further processing the data (e.g., filtering), storing the data, and distributing the data to a variety of client applications. Such client applications include both automated and manual supervisory control processes and display/monitor user interfaces.
Industrial process/operation measurements come in a wide variety of forms and are used by industrial process control systems to regulate a variety of operations, both with respect to continuous and discrete manufacturing processes. By way of example the measurements produced by a sensor/recorder include: a temperature, a pressure, a pH, a mass/volume flow of material, a quantity of bottles filled per hour, a tallied inventory of packages waiting in a shipping line, or a photograph of a room in a factory. Often, sophisticated automated process management and control hardware/software examine acquired process/operation measurement data, and respond by sending messages/signals to actuators/controllers that adjust the operation of at least a portion of the industrial process. The control software comprises, for example, one or more control strategies that, in turn, include a set of control blocks. The control programs potentially operate at a variety of levels of control including, for example, regulatory control (e.g., maintaining a particular specified set point for a process variable) and supervisory control (e.g., specifying a set point for a controlled process variable).
Automated control systems for typical industrial processes are often complex. Developing customized control programs for such automated control systems is, of course, a complex and time-consuming task. However, today control system programming is streamlined and simplified by graphical user interface-based control program development environments/toolkits that allow creation of control programs by dragging and dropping, and thereafter connecting, graphical representations of pre-programmed components/elements of a control program. Such graphical representations are associated with control software objects (or more specifically control software object templates) that, when instantiated and deployed on a control software object execution platform, carry out particular defined operations/functions in an overall control environment.
Programming automated control of processes using graphical editors and sets of selectable, pre-programmed, object templates is a substantial improvement over programming control using written instructions. The graphical user interface-based control program environment has substantially eliminated the need for control engineers to develop control programs using low-level instruction code, or even higher level compiled source code languages. Instead, developers of control programs invoke graphical control program editors having associated pre-programmed control objects represented by symbols provided in a control template pallet. Thus, instead of learning to program control using written instructions/code, programmers need only become knowledgeable with regard to various tasks/functions carried out by control objects instantiated from selectable control object templates.
Known graphical control program editors support an extensible set of control object templates. The new control object templates include new control elements with new attributes/functionality not found in existing control object template sets/pallets. In some instances the new control object templates are derived from existing templates. In other instances, the new control object templates comprise a set of connected, pre-existing, control object templates.
A particular class of control block, that is the subject of an editor described herein below, is capable of including both logical functions and arithmetic computations (including time measurements) in a single block. Such control block is referred to herein as a “LOGIC BLOCK” (all capitals to distinguish from the more particular LOGIC block described below). Examples of such LOGIC BLOCKs include: CALC, CALCA, MATH and LOGIC blocks in a known control block scheme provided by INVENSYS SYSTEMS, INC.
The CALC (calculator) block combines logical functions and arithmetic and Boolean computational capabilities within a single integrated programming environment component. The CALC block supports specialized control needs that cannot be met efficiently with either a standard block set offering or a sequence control block. The CALC block operates like most programmable pocket calculators. The CALC block's input/output modularity and programming capacity provides a level of functionality that complements the standard block set offering. Every program step within a CALC block contains an opcode, which identifies the operation to be performed, and one command line argument. The command line argument consists of the actual operand for the step, the location of the operand, a specification of details which further refine the opcode, or some combination of these factors.
The CALCA (Advanced Calculator) block provides both logical functions and arithmetic computational capability within one integrated programming environment component. The CALCA block provides dual-operand efficiency in several mathematical and logical instructions, resulting in as much as a three-to-one reduction in the length of a control program relative to the same calculations performed in a CALC block program. The CALCA block does not support clamping real outputs, whereas the CALC block does support clamping. With this exception, programs written for the CALC, MATH, or LOGIC blocks will execute in the CALCA block without change. The CALCA block supports entering up to 50 programming steps to a single block during configuration. Each program step is represented by a parameter string of up to 16 characters.
The LOGIC block provides both logical functions and timer capability within one integrated programming environment component. The LOGIC block supports specialized control needs that cannot be met efficiently with either a standard block set offering or sequence control blocks. The LOGIC block is modeled after the CALC block and can be used instead of CALC blocks in most control block data base configurations where logic or timer functions are required, but mathematical functions are not required since mathematical functions are not supported by LOGIC blocks.
The MATH (Mathematics) block provides mathematical programming capability and dual operand efficiency in several mathematical instructions. Dual operands can reduce the length of a CALC program which uses only single operands. The configuration process supports programming the MATH block by entering a series of up to 20 programming steps. Each program step is represented by a parameter string of up to 16 characters. The MATH block is used when mathematical functions are required but engineering ranges and logic/timer functions are not.
Thus, LOGIC BLOCKS operate much like a programmable pocket calculator, and have historically been programmed by using textual commands specified in Reverse Polish Notation (RPN). Although very powerful, correct use of RPN to define control programs requires training for those engineers who are not familiar with its non-intuitive syntax and rules.